Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000187_owner-urn-ietf _Wed Nov 20 12:01:12 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA04409 for urn-ietf-out; Wed, 20 Nov 1996 12:01:12 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA04403 for <[e-mail]>; Wed, 20 Nov 1996 12:01:09 -0500
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA04944  (mail destined for [e-mail]); Wed, 20 Nov 96 12:01:05 -0500
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA26282; Wed, 20 Nov 1996 10:00:53 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 20 Nov 1996 10:09:19 -0700
To: Bob Briscoe <[e-mail]>, [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] Resolution Services (N2L etc)
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Trolling back through my mail, I discovered that I had a few
partially-completed replies to the issues raised by Bob Briscoe,
but had not sent any of them. sigh. Here are some semi-random notes
on the things he raised.

Thus spoke Bob Briscoe (at least at 10:01 AM 11/5/96 +0000)

>Comments on draft-ietf-urn-naptr-00.txt:
>1.2 It strikes me that specifying available service requests (N2L, N2R etc)
>should not be the job of DNS or any URN resolution mechanism. You are adding
>metadata about the address that the name resolves to (i.e. allowed methods).
>NAPTR should simply get you to the place you asked for by mapping names to
>addresses.

The problem with this is that different places may offer different services.
The various resolution services offered by a resolver are is information about
the resolver and its capabilitities, not about the names on that resolver.

In another message lurking somewhere in my extremely well-organized mail
archives, I recall Bob saying that N2L was the only essential service, all
the others could either be reduced to it or were not important. I disagree,
not that this will surprise anyone. :-)  For the user, N2L and N2R are
equivalent, but N2R can avoid a round trip. N2C is very different from
N2L or N2R. Furthermore, I happen to think it is very important, and I
already have several exmples of where it might be used in early URN
experiments. The ISBN and UPC namespaces are both cases where we can
obtain a description of the resource (book or product) a lot easier than
we can obtain a copy of the resource. I have things going on at work where
we want tobe able to use N2C.

>IOW, the client should already know
>what it is going to do with the address it gets out of the URN service, or
>if it doesn't it should be prepared to find out.

That is not inconsistent with advertising the resolution services in a NAPTR
record. The clients know what they want to do - typically, get the resource
or at least a location for the resource. They can do this in several
fashions.  However, what the client wants to do may not be supported by
the resolver. If not, advertising those services in the NAPTR record lets
the client discover that early, and try contacting another resolver if
possible.


At 10:02 AM 11/5/96 +0000, Bob wrote:

>2. Substitution expression grammar
>2.1 You claim to be copying sed ERE syntax (with the caveat it may all
>change to cover UTF-8).

Not exactly. Sed uses Basic Regular Expression syntax, I suggest that
we use Extended Regular Expression syntax.

> To avoid confusion for sed gits like me, could you
>consider using the escaped parentheses \( and \) to do back refs, rather
>than the one character ones ( and ) which simply imply grouping in POSIX
>EREs by my understanding.

This is the big difference between BRE and ERE syntax. I suggested
using ERE because I think it is going to be simpler for people to
use () than \\(\\). At the time there was some agreement with this
argument, and I don't recall any disagreement. However, if others
come forward to ask for BREs I will certainly consider changing the
draft.


>2.2 Also, it would be friendly to allow any delimiter, like sed does, not
>just "/" (e.g. "!.*//\([^/:]+\)!\1!i" is a lot more readable than
>"/.*\/\/\([^\/:]+\)/\1/i").

Agreed. I'll change the draft on this point to say something like:

"The first character of the substitution expression will be used as the
delimiter character. There MUST be exactly three non-escaped occurrances
of that character in the substitution expression. Because escaped
digits in the replacement portion of the substitution expression are
backrefs, the delimiter character MUST NOT be a digit. Similarly, the
delimiter character MUST NOT be a flag character if that flag is used
in the substitution expression.


I believe Bob's main objection to the NAPTR draft was that there was no
way of indicating the lifetime of a resolver. I'll take that up with him
off-list because I am still not clear on aspects of that objection.

Regards,
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"